This invention relates generally to databases for digital data storage and retrieval, and more particularly to the management of physical file system objects such as files and directories created or dropped on mirrored databases.
Enterprises employ database systems comprising mirrored databases as a repository of the enterprise's stored data, and such systems provide architecture to support operational systems such as online transaction processing (OLTP). The databases generally have large sizes, store large volumes of data, and experience high numbers of operations.
Mirrored databases comprise a primary database and a mirror database pair that are synchronized by redundantly writing the same data to both databases for backup and to assure high availability of the data if one of the databases fails (crashes). In the event of a crash, or loss of communications with a database, a mirror resynchronization process is performed by the system to manage the creation and deletion of file directories and file objects on both mirrors that store database data to restore the databases to a synchronized state. Mirror resynchronization will re-create file system objects that may not have been created and attempt to remove objects that were logically dropped while the mirror was down. Additionally, if a crash occurs during a transaction, physical file system objects that may have been created by aborted database transactions and those that may have been dropped by committed database transactions may remain. Mirror resynchronization needs to know which file system objects to clean up on the mirrors that were logically deleted and which file system objects to re-create that were logically created while the mirror was down. Frequently, this information is not readily available.
The file systems used in databases typically do not support external local or distributed transactions, and have no mechanism for accurately and durably recording which file system objects are in use by the database. Moreover, some database systems do have a crash recovery undo so that there is no mechanism to remove physical objects by an aborted transaction during crash recovery. They can only do redo operations during crash recovery by replaying and redoing all work recorded in a transaction log, such as a Write Ahead Log (WAL), since a last database checkpoint. For large databases, this can be a very lengthy process. The database systems generally lose track of file directories and files used by the database when the database crashes, and physical files would be left around with old database data and would occupy disk space without the knowledge of the database, which can hamper performance. With mirrored databases, this situation is exacerbated.
It is desirable to provide systems and methods that address this and other problems of resynchronization of mirrored databases following a database crash by facilitating cleanup of physical file system objects from the databases, and it is to these ends that the present invention is directed.